IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to provide appropriate levels of Quality of Service (QoS), as well as to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP),
A number of different identities are associated with the IMS, including private user identities—IP Multimedia Private Identity (IMPI)—and public user identities—IP Multimedia Public Identity (IMPU). Both IMPIs and IMPUs are Uniform Resource Identifiers (URIs) that can be a sequence of digits (a Tel URI) or alphanumeric identifiers (a SIP URI). IMS identities are stored in a subscriber database, referred to as a Home Subscriber Server (HSS), together with subscriber service profiles, service triggers and other information. Every IMS user shall have one or more IMPIs.
The IMPU is used by any user for requesting communications with other users and can be published (e.g. in phone books, web pages, business cards). Multiple IMPUs can be associated with a single IMPI. An IMPU can also be shared between several terminals, so that several terminals can be reached with the same identity (for example, a single phone-number may be shared by an entire family).
IMPUs may be stored in the HSS as wildcarded Public User Identities (wIMPUs). The wIMPU represents a collection of IMPUs that share the same service profile and are included in the same Implicit Registration Set (IRS), where an IRS is a group of IMPUs that are registered via a single registration request. When one of the IMPUs within the set is registered, all IMPUs associated with the IRS are registered at the same time. wIMPUs include a regular expression (reg exp) that defines the identities that should be matched and handled as defined for the wIMPU.
wIMPUs enable telecommunication network operators to cooperate with third party wholesale and corporate organisations who in turn maintain end user relationships, with those relationships not necessarily being known to the telecommunication network operators. Such arrangements mean that the end users are not themselves provisioned and thus able to register with the IMS system (using the HSS): it is only the identity of the wholesale partner or corporate organisation that is known and it is this identity that, for example, triggers the services that shall be executed (i.e. it is tied to a certain service profile). The approach assigns one or more wIMPUs to the wholesale partner (WSP) or corporate organisation, and users belonging to the partner or organisation will be associated with the wIMPU(s). In the following discussion, the term “WSP” (also “WP”) is used to indicate both wholesale service providers and corporate organisations, or any other organisation that makes similar use of wIMPUs.
It is noted that certain references made below to the wIMPU should be taken as referring to that specific IMPU (from within the wIMPU range) that is registered by the WSP. Signalling for all users associated with the WSP will use the same, registered IMPU to allow for common service handling by the IMS.
A WSP will connect to the IMS network via an IMS Access Edge Gateway. This IMS Access Edge Gateway permits interconnection of two operator domains. [The IMS Access Edge Gateway may be collocated, as a front-end, with a Proxy Call Session Control Function (P-CSCF).] In this case, one of the domains is the IMS network whilst the other might be the Internet. As an example, one might consider an end user that subscribes to an Internet-based auction site. That auction site is the WSP in this example. A user (potential buyer) registers with the site using his or her external identity, i.e. an auction site username such as “userA.auction.com”. The auction site returns a token to the user, and the user then performs a SIP registration with the IMS Access Edge Gateway of the IMS network, sending to the Gateway the user's external identity and the token. The IMS Access Edge Gateway then authenticates the user, identifies the relevant WSP/wIMPU, and records the association between the external identity and the wIMPU in a wholesale database.
Once registered, the user may click on a link on a web page of the auction site to set up a call to a seller of an advertised item. The buyer's terminal then sends a SIP INVITE to the IMS Access Edge Gateway. The P-preferred-Identity of the INVITE is the external identity of the buyer, while the Request-URI is the external identity of the seller. The IMS Access Edge Gateway performs a lookup on the wholesale database in order to identify the wIMPU associated with the buyer's external identity (as noted above, this wIMPU may be the “common” registered IMPU from within the wIPMU range). The IMS Access Edge Gateway includes the wIMPU in the P-profile-key field of the INVITE and forwards it towards the originating side S-CSCF where the INVITE is handled according to the wIMPU service profile. The presence of an entry in the P-profile-key field flags up to the S-CSCF and any Application Servers in the originating side signalling path that the INVITE should be handled using the wIMPU included within that field, rather than the external user identity (WSP) contained within the P-preferred-Identity. The INVITE will be further routed across the IMS to the terminating side S-CSCF, typically based upon the domain within which the seller resides, e.g. “auction.com”. At the terminating side Interrogating Call Session Control Function (I-CSCF), that domain will be mapped to a wIMPU associated with the seller's WSP, and that wIMPU inserted into the P-profile-key field to allow appropriate handling of the INVITE by the terminating side S-CSCF and ASs.
A WSP such as an auction website may operate across a number of geographical regions. In order to correctly route traffic within a single IMS operator's domain (i.e. where the IMS network does not utilise sub-domains), the WSP will be allocated one or more different wIMPUs for each region. Of course, a given user may connect to the WSP from different regions in which case the wIMPU associated with that user may change from time to time. Routing the INVITE towards the destination is therefore problematic.
Within the IMS network, it would be possible to provide an interface between the I-CSCF and the wholesale database to allow the I-CSCF to fetch from that database the wIMPU associated with the WSP user identified in the Request-URI. This assumes of course that the wholesale database is dynamically updated with internal (wIMPU) and external (WSP) identity associations—this would be relatively easy when both the called and the calling party are registered with the same WSP. In the case of different regional wholesale databases, or where a number of WSPs interoperate, replication of a number of databases may be required.
FIG. 1 illustrates this possible approach, where signal 1 indicates the SIP INVITE sent by the calling party “A” in order to establish a connection to the called party “B”. Signal 2 indicates the lookup stage which provides A's wIMPU to the P-CSCF on the originating call side (it is assumed that the IMS Access Edge Gateway is co-located with the P-CSCF). [NB. Signal 2 may not be required if the Gateway has cached the association between user A's external identity and the wIMPU.] Signals 3 to 6 indicate standard IMS setup signalling. The originating side S-CSCF and As(s) handle the INVITE according to user A's wIMPU included in the P-Profile-key field. Step 7 illustrates the lookup stage where the I-CSCF, on the terminating side, obtains user B's wIMPU using user B's external identity (or at least the domain part). Steps 8 to 12 indicate standard IMS setup signalling, where the terminating side S-CSCF and As(s) handle the INVITE according to user B's wIMPU included in the P-Profile-key field. [It is assumed of course that the terminals of users A and B both incorporate appropriate SIP clients.]
FIG. 2 further illustrates this approach, and includes signalling to register the association of a user (A) with a wIMPU in the wholesale database. More particularly, the signalling consists of the following:                1. The WP user logs into an application that has voice capabilities and it sends a Register to the PCSCF (using SIP or e.g. HTTP via a terminal adapter) in order to be able to call and receive calls.        2. The PCSCF checks that this is a valid user and may also do certain things depending on the domain of the user such as fetching additional information from the WP but we assume now that all needed information is stored in the wholesale DB. The PCSCF checks the DB and also stores the relation between the user's external identity and the wIMPU used and the address, to this PCSCF.        3. User A wants to call User B and sends an Invite to the PCSCF.        4. The PCSCF may now check information of user A in the database but it is assumed that this data can also be cached at the PCSCF.        5. The PCSCF sends the request including the used wIMPU and the external identity of the calling party to the originating SCSCF.        6. The SCFCF fetches the service profile for the wIMPU of the originating user from the HSS to see if any services shall be executed (which is not the case for this call).        7. The originating SCSCF sends the request including the used external identity of the caller and the external identity of the callee to the terminating ICSCF (routing uses the domain of User B's external (WSP) identity).        8. The ICSCF checks the wholesale DB to find the SCSCF and possibly also the address of the PCSCF (this may not be needed since the SCSCF may have that as part of the contact information when the PCSCF registered the wIMPU.        9. The ICSCF sends it to the SCSCF which in turn fetches the service profile for the wIMPU of the terminating user from the HSS to see if any services shall be executed (which is not the case for this call).        10. The SCSCF sends the request to the PCSCF        11. The PSCF sends the request to user B        